Shareware Grab Bag/Shareware Grab Bag.iso/014/bacopy.arc/BACOPY.DOC

Text File | 1985-07-18 | 9.8 KB | 162 lines

                   End Big Blue's Backup Blues
   (PC Magazine Vol 4 No 17 August 20, 1985 by John Dickinson)

    Backups should be made on a regular basis whether you work
with a floppy disk-based PC or with a hard disk machine such as in
the XT or enhanced AT.  Unfortunately, PC-DOS doesn't make the job
very easy.  Floppy disk users can make use of the DISKCOPY command
to make backup copies of their disks.  Users with hard disks are
stuck with the PC-DOS BACKUP command.  This latter makes copies of
files that cannot be used until after they have been returned to
the original disk by using the RESTORE command.
    Neither command works very quickly, so many users prefer
the COPY command as a faster alternative.  With COPY they can make
discretionary incremental backups of only the files that have been
changed since the last backup was made.  For hard disk users, COPY
offers the added benefits of quick restoration, the ability to peek
at the last version of a file, and the ability to use the file
directly on another system should yours go down because of a hard
disk failure -- facilities you lose with the BACKUP command.  (Note
that there is no good substitute in the standard PC-DOS environment
for BACKUP and RESTORE when it comes to making periodic, say, weekly
backups of your entire hard disk.)
    There are two problems with using COPY as a general backup
utility.  First, the task of deciding which files to back up is left
to you.  If you're like me, that means you copy all the files in a
directory or on a disk rather than chance missing one you forgot you
had changed.  That can take a long time.  The other problem is that
if you're copying a large directory from a hard disk to a floppy
disk, the target floppy can get full if you copy all the files to it.
Deciding which files did and did not get copied to the first disk and
then copying each remaining one to a second disk is a major annoyance.
    All that's really needed to cure both of these ills is a
command that's slightly more intelligent than COPY, but without all
the sophistication of BACKUP.  The command should copy only the files
that have been altered onto a target floppy disk, and should be able
to continue on to a new disk when the original fills up.  Fortunately,
it isn't difficult to create an assembly language command called
BACopy that does the trick.
    BACopy works very much like the COPY command, even down to
using almost the same source-to-target syntax:
        [d:][path]filename[.ext] [d:] [path]
    Like COPY, BACopy allows making backup copies of files from
any source disk and directory to any target disk and directory.  This
lets you make spare copies on the same disk in different directories,
for example.  It also allows PC-DOS wildcard notation to be freely
used.
    The only exception to COPY's syntax is that BACopy does not
allow renaming the file during the copy process.  To do so would make
the backup strategy needlessly confusing.  (You could, of course, fool
BACopy into making extra copies by renaming files on the target disk
when it's through working, but that's up to you.)
    BACopy makes more important exceptions to COPY's rules when
it comes to how the program works.  BACopy checks for the existence
of each file you requested it to copy on the target disk.  If the
file is already on the target disk, however, BACopy compares the save
date and time of the source and target files and only copies the
original to the target if the original file is newer.
    The other exception to COPY's procedure is that BACopy doesn't
quit if you run out of disk space.  It recovers from a target disk-full
error by asking you to insert another one so it can continue with its
work.
    BACopy does not disturb the archive bit in the source file's
directory.  This bit is used to indicate whether or not a backup has
been made.  As it was designed to be, changing the archive bit remains
the prerogative of the BACKUP command.  BACopy's backup strategy does
depend on you to set your PC's clock to the correct time and date when
you start your system, of course.  If you do that, your file's time
and date stamps will correctly indicate if and when you have modified
your files.
    The source code for BAC.COM is written in assembly language,
and the full, commented listing is 7 pages long.  You can obtain
BACopy in its assembler version by downloading it from PC Magazine's
Interactive Reader Service (212-696-0360).  The code will assemble
using either IBM's or Microsoft's assembler.  After linking it with
the PC-DOS LINK command, make sure to convert it to a .COM file
using EXE2BIN.  The BACOPY.BAS program automatically creates BAC.COM.
    Like most programs, BACopy starts out by parsing the command
line.  Here we need to know the source disk, directory and filename
(including extension, if present), as well as the target disk and
directory.  The code in BACopy will look familiar to those of you
who worked with the REDirect program (PC Magazine, Volume 4 Number 4).
That's no surprise, since it's the same, and you can just copy it into
your new file if you have a working copy of REDirect's source code.
    PC-DOS function calls 4EH and 4FH are used to find the source
file: This technique is what allows wildcards to be used.  As each
file is found, the target file is looked for by using function call
4FH.  If the target is not found, BACopy goes directly to the routine
for opening the source file, creating the target and copying the
source file into into.
    If the target file exists, the save dates and times of the
two files are compared.  I do this by looking at the words at byte
24 (date) and byte 22 (time) in the Disk Transfer Area (DTA) for each
file.  (A PC-DOS function call, 57H, would do this, but it takes
longer than my procedure because the files have to be opened first.)
If the date of the target file is the same or newer than that of the
source file, BACopy won't make a new copy.  In this case a utility
subroutine is called to make sure any open files are closed.  The
program then goes on to look at the next file.
    When a target file must be created, the source file is
opened, and a file handle is assigned by calling PC-DOS function
call 3DH.  The target file is then created by using function 3CH.
A handle for the target is assigned to PC-DOS when 3CH is called.
The reason BACopy creates the target, rather than opens it, is two-
fold.  First, the same code works whether or not the target file
exists, and second, the file size in the directory entry will be
correctly updated when the new copy of the file has fewer bytes
than the old version.
    Blocks of data are then moved from the source file into
memory and then to the target file.  The size of each block is
determined by the distance between the top of available memory
(which is just below the stack area of a .COM file) and the end of
the program.  The current versino of BACopy yields a BLKSIZE of
about 62K bytes, which is about the size of the memory buffer used
by the COPY command.
    Using function call 3FH, each read request asks PC-DOS to
read the BLKSIZE bytes.  If fewer are returned than expected (this
can be determined by looking at the AX register when Interrupt 21H
returns), the last available block of data has been read.  Unless
no bytes were read, the write request (PC-DOS function call 40H)
asks that the same number of bytes read from the source file to
the target file.
    If the requested number of bytes was written, so the
program has not reached the last block, BACopy returns and continues
working.  If it hits the last block of data, BACopy jumpts to the
clean-up routines.  There it uses PC-DOS function call 57H to get
the source file's time and date stamp and apply it to the target
file (writing into the DTA doesn't do the trick, though you might
think it would).  If BACopy didn't do it this way, the target file
would have the current time and date in its directory when it gets
closed, and part of BACopy's design purpose would be defeated.
Again, this exactly parallels the COPY command.
    If the requested number of bytes was not written, it means
that the target disk is full.  Rather than just quit, however, as
the COPY command does, BACopy provides a recovery routine.  It
closes all files, erases the target file as it exists so far, and
requests that you insert a new disk in the target disk drive.  The
program will not proceed further until you press the Enter key,
and it will stop if you press the Ctrl-Break combination instead.
While this technique is not nearly as clever as BACKUP's trick of
spanning files across disks, it will do just fine for most users
who want to make incremental backups.
    If, at the end of everything, BACopy finds out it didn't
modify or create any target files, it tells you there was nothing
to back up.  That message will only appear if all source files
exist on the target disk and directory and are the same dates or
older than the target files.
    I've been using BACopy on a daily basis for some time now,
and have found it most helpful.  It's a fraction of a second slower
per file than COPY when you're running it for one file, but it saves
so much time as you update your overall group of files that this
slight performance penalty is well worth it.  Most of the batch
files I use to move about my hard disk and Bernoulli Box know how
to run BACopy at appropriate moments.  If a target disk isn't ready,
PC-DOS tells you about it -- BACopy doesn't have to worry.
    Depending on which directory and disk I'm using, an ordinary
floppy, the AT's high density floppy, or one of the Bernoulli Box
disks is BACopy's target.  All three work fine with BACopy, and the
higher-density disks make it reasonable to have floppy disk
directories to house your backups, a feature unsupported by the
BACKUP command.